Architectural Technical Debt: Models and Impact

A known problem in large software companies is to balance the prioritization of short-term with long-term responsiveness. To illustrate such a phenomenon, a financial metaphor has been coined, which relates taking sub-optimal decisions in order to meet short-term goals to taking a financial debt, which has to be repaid with interests in the long term. Such a concept is referred to as Technical Debt (TD), and recently it has been recognized as a useful basis for the development of theoretical and practical frameworks (Kruchten et al., 2012). Tom et al. (Tom et al., 2013) have explored the TD metaphor and outlined a first framework in 2013. Part of the overall TD is to be related to architecture sub-optimal decisions, and it’s regarded as Architecture Technical Debt (ADT). ATD is regarded as violations in the code towards an intended architecture. The problem of visualizing and communicating the ATD is particularly relevant for large companies, where the architecture documentation is not capable of capturing all the updated information for compliance checking of the source code. It’s therefore difficult, both for software architects and managers not involved directly in the development of parts of the system, to monitor and understand the level of current ATD. This, in turn, affects negatively their ability of taking informed decision about the prioritization of architectural improvements and refactorings and about estimating the time needed for product development. ATD has been recognized as part of TD, but the specific phenomenon of accumulation of ATD, its recovery to avoid the later payment of interest (in terms of effort) and the impact (effects) of such interest in future development has not been tackled yet.